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(54) A method for generating localizable message catalogs tor java-based applications 



(57) A method for generating localizable message 
catalogs for Java-based applications is disclosed. Mes- 
sage catalogs that are automatically flagged for what 
needs to be manually translated are generated from a 
given Java source code file (46, 78), which can then be 
used for translation (Figure 5, 80). ListResourceBundle 
data structures that are compatible with Java's interna- 
tionalization model are also generated from the mes- 
sage catalogs that were previously generated (82) and 
manually translated into desired local language(s) (64, 
80). This provides a more efficient means of maintaining 
a language-specific version of Java software after if has 
been released. 
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Description 

FIELD OF THE INVENTION 

5 [0001] The present invention relates generally to windows-based computer applications, and more particulariy to 
localizable message catalogs for Java-based applications. 

BACKGROUND OF THE INVENTION 

10 [0002] The increasing use of the Intemet and other distributed networks for a variety of purposes, including inter- 
national commercial, scientific and cultural discourse, makes the ability to readily and reliably produce and support glo- 
bal software increasingly important. Global software, or apprications, refers to software that is developed independently 
of specifk: languages or geographic regions and capable of being translated into any desired language or region of an 
end user at run-time. 

75 [0003] The Internationalization process implies that the software consists of a single set of binaries that operates 
under all languages, and that the language-sensitive areas in the source code, referred to as the 'localizable areas', 
such as end-user visible strings, data and numeric formats, are stored in external files. The C/C++ programming lan- 
guage, for instance, uses this internationalization model by storing the language-sensitive areas in external files called 
'message catalogs'. Message catalogs are based on the standard defined by the X/Open Portability Guide (XPG) and 

20 are thus very attractive for localization. These message catalogs are not source code but are text files, designed for 
localizabilfty, that allow easy translation of texts into native languages, such as French, Italian, Russian, Gemnan or Jap- 
anese. The C/C++ programming language 'loads' the appropriate language versions of these message catalogs based 
on the end-user's language at run-time. When a user starts up an internationalized application, the application first 
checks to see whteh locale is in use by the user. For instance, when a user runs an application on a Gemnan NT server, 

25 the user is using the German locale. The locale in use by the user, detemnined at run-time, will be used by the applica- 
tion for the display text and other user interface elements. If the user changes the locale in use, such as by restarting 
the desktop environment under another locale, the application will use that other locale to display the texts and other 
user interface elements. 

[0004] This intemationalization approach is not available for software written in the portable Java programming lan- 

30 guage by Sun Mk^rosystems because the Java programming language does not store language-sensitive areas in the 
source code in message catalogs. The Java programming language provides a framework for developing global appli- 
cations which allows for translation of end-user visible strings, refen-ed to as 'display strings' or 'locaHzable strings," 
that may be shown to an intended user and therefore need to be translated for different countries. A Java global appli- 
cation is comprised of a collection of related Java source code files, hereafter refen^ed to as a 'package'. Each of the 

35 Java source files contained in a package may contain display strings. To produce global software, these display strings 
need to be translated to different countries or languages of the intended users. This translation includes translation of 
messages, numbers, dates, and currency into a country's conventional fomiats. Non-display strings, such as comments 
and Universal Resource Locators (URLs), are used progranunatically and are thus not translated. 
[0005] As mentioned, the Java programming language does not store display strings in message catalogs but 

40 instead stores language-sensitive areas in a source code data structure refered to as a 'ListResourceBundle'. Basi- 
cally, a ListResourceBundle data structure provides a way to access display strings according to locale conventions. 
The ListResourceBundle data structure has a unique identifier to a display string, referred to as a 'display string key", 
that enables 'display string value' mapping. A Java ListResourceBundle data structure can be stored in a separate 
external file and loaded at runtime. 

45 [0006] Rgures 1 -2 provide an example of how Java programmers use existing Java methodology to internationalize 
a Java program and then how translators, also called localizers, subsequentiy localize the intemationatized Java pro- 
gram. Referring to the flow chart 10 of Rgure 1 , the first step, shown at Block 12, for intemationalizing a Java program 
is to identify the localizable areas, such as localizable strings, within the Java source code. For purposes of this example 
only, assume that the Java code of interest is contained in a file named 'myApplication.java': 

50 

r 'Display adjustment" and "Volume adjustmenf are the */ 
r strings that needs to be made localizable. As it appears V 
r in this manner, they cannot t)e translated. */ 
myCheckboxl = new Checkbox("Display adjustment^; 
55 myCheckbox2 = new CheckboxCVolume adjustment"); 

[0007] It wilt be understood that only two strings have been shown in the example for ease of explanation and that 
one skilled in the art will recognize that Java source code will typically have dozens or even hundreds of strings. The 
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next step, at Block 1 4, is to create a unique key for each of the identified localizable strings. Assume that the key for the 
localizable string 'Display adjustmenr will be •display_adj" and that the key for the localizable string •Volume adjust- 
ment" will be Volume.adj'. At Block 1 6, the next step is create a subclass of a ListResourceBundle and override Its get- 
ContentsO method that will contain the localizable string(s). The following is some sample Java code In a file called 
5 "myResourcesjava": 

import java.util.*; 

public dass myResources extends ListResourceBundle { 

10 

public ObjectQD getContents() { return contents }; 
static final ObjectOD contents = { 
{"display_adj", "Display adjustment"}, 

15 

{"volume_adj", "Volume adjustmenr} 

}: 

20 }l 



[0008] Then, the locale in the source code must be determined so that the correct language version of ListRe- 
25 sourceBundle can be loaded/accessed by the Java program at run-time, as shown in Block 1 8. Sample Java code that 
will accomplish this step is shown below and will be added prior to the Java code associated with Block 12 above: 

r Obtain the locale information for this application. */ 
r If this Java program is running in French mode, */ 
30 r "getDefauttO" will return French. V 
Locale locate; 

locale = Locale.getDefauttQ; 

/* Use the locale infomrtation (from above) to obtain the */ 
35 r locale-specifb version of nnyResources. So, if the locale 7 

/* is set to French, the "getBundleO" will return a French */ 
r language version of the ListResourceBundle. V 
public static ResourceBundle rb; 
rb = ResourceBundle.getBundle("myResources", locale); 

40 

[0009] Rnally, at Block 20, the localizable string(s) are obtained from the UstResourceBundte. Sample Java code 
to accomplish this step in the "myApplication.java" file follows: 

r Obtain the locale information for this applrcation. */ 
45 rif this Java program is running in French mode, V 
/* "getDefaultO" will return French. V 
Locale locale; 

locale = Locale.getDefaultO; 

50 r Use the locale information (from above) to obtain the */ 

r locale^pecific version of myResources. So, if the locale V 

/* is set to French, the 'getBundleQ" will retum a French */ 

r language version of the ListResourceBundle. V 

public static ResourceBundle rb; 
55 rb = ResourceBundle.getBundleCmyResources", locale); 

r Obtain the localizable strings by calling "getStringO" V 
r and by passing the key for each of the localizable strings. */ 
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/• So, if the above calls fetched a French ListResourceBundle, 7 
r myResources.rb.getStringCdisplay_adj') */ 
r will return the French translation of the string V 
r ■Display Adjustment" V 

myCheckboxl = new Checkbox(nrTyResources.rb.getString("display_adj'); 
myCheckbox2= new Checkbox(myResources.rb.getStringCvolume_adj"); 

[0010] The Java program has thus been intemationalized according to the prior art method of Rgure 1 . Now sup- 
pose that the intemationalized Java program must be translated or localized to the desired locale. This methodology is 
illustrated by flow chart 30 of Rgure 2. The first step, at Block 32, is to obtain the ListResourceBundle for a given Java 
program that is to be localized. The ListResourceBundle will consist of Java code with "{key, value}" pairs. Sample Java 
code in the "myResourcesJava" flie that will accomplish this step follows: 

import java.util.*; 

public class myResources extends ListResourceBundle { 
public ObjectOD getContents() { return contents }; 
static final ObjectQD contents = { 
^display_adj^ "Display adjustment*}. 



fvolume^adj", "Volume adjustment"} 

}; 

}: 



[0011] The next step, at Block 34, is to translate only the "value" portion and not the "key" portion of the ListRe- 
sourceBundle source code data structure, being sure not to modify anything else within the source file. The flie may be 
renamed to indk^te the translation language. For instance, the French version of the "myResourcesjava" file may be 
titled the "myResources_fr.java" file. Sample Java code in the ■myResources_fr.java" file may be as follows: 

import java.util.*; 

public dass myResources extends ListResourceBundle ( 
public ObjectflD getContents{) { retum contents }; 
static final ObjectOD contents = { 

fdisplay^adj", "Re'glage d'affichage"}, 

rvolume_adj", "Re'glage de volume"}, 

}; 



[0012] Unfortunately, using a ListResourceBundle data structure presents several disadvantages, as can be seen 
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from the above example. Rrst, ListResourceBundte data structures are source code and are therefore not easity trans- 
latable. Translators cannot use any of the 'localization tools' applicable for message catalogs and the difficulty becomes 
distinguishing display strings which need to be translated from non-display strings which do not require translation. The 
Java code thus has to be combed manually, I.e. line-by-line, to identify the display strings that need to be translated. 
5 The display strings must then be changed manually to make it translatable. Needless to say, this process is very time- 
consuming and inefficient. While mechanisms such as PERL script may be used to assist in this endeavor, the results 
must still be checked manually. 

[001 3] Second, writing Java source code that loads and accesses a ListResourceBundle data structure is cumber- 
some. Additionally, identifying obsolete or new or modified strings that require new translations is difficult using a Lis- 

10 tResourceBundle data structure. Modifying the Java source code without translating the accompanying 
ListResourceBundle c^ta structure will cause the Java program to throw an exception, sometimes referred to as throw- 
ing an exception,' similar to a core dump in a C program, for not being able to find a translated string. Rnally, modifying 
an existing non-global application to use ListResourceBundle data structures is difficult because the process of sepa- 
rating the display strings from the Java source code generally cannot be done automatically. It is much easier to build 

15 a global program from the ground up rather than attempt to retrofit an existing non-global application because of this 
difficulty. It is therefore difficult to modify an existing Java-based non-global appftcation to make it capable of using Lis- 
tResourceBundle data structures. 

SUMMARY OF THE INVENTION 

20 

[001 4] It is therefore an object of the present invention to provide easily translatable display strings for the Java pro- 
grannming language. It is another object of the present invention to provide a less cumbersome means of loading and 
accessing a ListResourceBundle data structure. It is yet another object of the present invention to identify obsolete or 
new or modified display strings that require new translations. Rnally, it Is an object of the present invention to provide a 
25 means of converting an existing non-global application into a global application using ListResourceBundle data struc- 
tures. 

[0015] Therefore, according to the present invention, a methodology for generating localizable message catalogs 
for Java-based applications is disclosed. Message catalogs that are automatk^lly flagged for what needs to be manu- 
ally translated are generated from a given Java source code file, which can then be used for translation. ListResource- 

30 Bundle data structures that are compatible with Java's internationalization model are also generated from the message 
catalogs that were previously generated and manually translated into desired local language(s). The methodology com- 
prises: identifying one or more localizable strings of a Java source code; marking the one or more localizable strings to 
produce one or more marked localizable strings by inserting a marker into each localizable string of the one or more 
localizable strings that are function calls to an internationalization tool; extracting the one or more marked localizable 

35 strings; storing the one or more marked localizable strinc^ into an external text file, such as a message catalog file; and 
generating one or more ListResourceBundle data structures from the one or more marked localizable strings stored in 
the external text file. Extracting and storing the one or more marked localizable strings into one or more text files and 
generating the one or more ListResourceBundle data structures occurs when the Java source code ts compiled. The 
one or more ListResourceBundle data structures are generated by: determining a cun-ent locate language in which the 

40 Java source code is running; determining whether the current locale language is a default language; if the current locale 
language is the default language, returning a marked localizable string of the one or more marked localizable strings; if 
the current local language is not the default language, determining whether a language-specific version of the marked 
localizable string that corresponds to the current locale language exists in a ListResourceBundle data structure of the 
one or more ListResourceBundle data structures that connesponds to the mariced localizable string; and if the language- 

45 specific version exists, opening the ListResourceBundle that connesponds to the marked localizable string and retuming 
the language-specific version of the marked localizable string fi'om the ListResourceBundle. The one or more marked 
localizable strings of the Java source code can be translated by: obtaining the extemal text file containing the one or 
more marked localizable strings; translating the one or more mariced localizable strings stored in the external text file; 
and generating a ListResourceBundle data structure for the translated one or more marked localizable strings. 

50 [0016] After storing the marked localizable strings into the extemal text file, the methodology further comprises: 
generating a new version of the Java source code in a second directory from whtoh an internationalization tool is run; 
retrieving the mariced localizable strings from a ListResourceBundle class; and generating a merged extemal text file 
containing the one or more mariced localizable strings in the first directory and the second directory. ListResourceBun- 
dle files corresponding to the merged extemal text file with each ListResourceBundle file of the one or more ListRe- 

55 sourceBundle files con^esponding to a desired language are generated. 

[0017] The above methodology is accomplished according to the following: opening an original Java source code 
file that is stored in a first directory; opening a first message catalog file; copying the first message catalog file to a sec- 
ond message catalog file; creating a modified Java source code file fi^m the original Java source code file in a second 
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directory; reading the contents of the original Java source code file into a buffer; if the buffer contains one or more 
nnarked tocalizable strings, for each marked localizable string of the one or more marked localizable strings comprising: 
obtaining a message number corresponding to the marked localizable string and replacing the mariced localizable string 
in the buffer with a method call that can obtain the mariced localizable string if the marked localizable string is stored in 
5 the first message catalog file, or appending the marked localizable string to the second message catalog file and 
removing a marker from the mariced localizable string in the buffer to convert the marked localizable string to a default 
localized string if the marked localizable string is not stored in the first message catalog file; writing to the modified Java 
source code file from the buffer; and closing the original Java source code file, the first message catalog file, the second 
message catalog file, and the modified Java source code file. 

10 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0018] The novel features believed characteristic of the invention are set forth in the claims. The Invention itself, 
however, as well as the pretended mode of use, and further objects and advantages thereof, will best be understood by 
15 reference to the following detailed description of an illustrative embodiment when read in conjunction with the accom- 
panying drawing(s), wherein: 

Rgure 1 is a flow chart for intemationalizing a Java program, according to the prior art; 

20 Rgure 2 is a flow chart for translating or localizing the Java program, according to the prior art; 

Rgure 3 is a flow chart that illustrates the methodology for internationalizing a Java progreim and then translating 
the intemationalized Java program to a desired locale, according to the present invention; 

25 Rgure 4 is a flow chart that illustrates the MsgHandler.java class, including the *getString" method, according to 
the present invention; 

Rgure 5 is a flow chart that illustrates the methodology for translating or localizing a Java program, according to 
the present invention; 

30 

Rgure 6 is a flow chart that illustrates the methodology of the present invention; and 

Rgure 7 is a flow chart that illustrates the methodology of the present invention, with emphasis on identifying mod- 
ified strings that require new translations. 

35 

DESCRIPTION OF THE INVENTION 

[0019] The method for generating localizable message catalogs for Java-based appPtcations of the present inven- 
tion provides a mechanism whereby a ListResourceBundle data structure file is automatk^lly generated from an exist- 

40 ing Java source code file using an intenmediate message catalog file that may be manually translated to a local native 
language to provide global software that can operate under various native language environments and thus is capable 
of being used worid-wide. This mechanism of the present invention, referred to as the internationalization tool, gener- 
ates Unix-style message catalogs as Intermediate files and then generates ListResourceBundle data structures from 
those intermediate message catalogs. Without the internationalization tool, the programmer must manually create the 

45 ListResourceBundle data structures used by Java to create localizable strings. When a user starts up an intemational- 
ized Java-based application, the application determines the locale in use by the user and that locale will be used by the 
appftcation for the display text and other user interface elements. 

[0020] Therefore, according to the present invention, a method for generating localizable message catalogs, in 
whk^h there is one message catalog file per Java package-and not per Java class-is disclosed. Rrst, the present inven- 

50 tion generates message catalogs automatically from a given Java source code, whk:h can then be used for translation. 
Next, the present invention automatteally generates the ListResourceBundle data structures from the message cata- 
logs that were derived and translated so that the final result is compatible with Java's internationalization model. Rnally, 
the present invention automatically flags what needs to be translated providing a more efficient means of maintaining a 
language-specific version of Java-based software after it has been released. 

55 [0021 1 Refening now to Rgures 3 — 7, the methodology of the present invention for internationalizing a Java pro- 
gram and then translating the intemationalized Java program to a desired locale is described. Referring first to the flow 
chart 40 of Rgure 3, the Java programmer identities the localizable string(s) within the Java source code that make up 
a Java package at Block 42. These localizable string(s) include previously localized strings, modified strings, and new 
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strings. There is one message catalog per Java package, not per Java class. This step is similar to Block 12 of Rgure 
1 and sample Java code in file 'myApplication.java' follows: 

/• "Display adjustment" and "Volume adjustment" are the */ 
5 r strings that needs to be made localizable. As it appears V 

r in this manner, they cannot be translated. V 
myCheckboxl = new Checkbox("Display adjustment"); 
myCheckbox2 = new Checkbox("Volume adjustment"); 

10 [0022] The next step, at Block 44, is for the programmer to insert a "><" marker for each of the localizable strings. 
The file "nnyApplication.java" is modified in this manner 

r "Display adjustment" and "Volume adjustment" are the V 
r localizable strings. V 
15 myCheckboxl = new CheckboxCxDisplay adjustment"); 
myCheckbox2 = new Checkbox("><Volume adjustmenH; 

[0023] The localizable display strings "Display adjustment" and "Volume adjustment" of the file "myApplication.java" 
are easily identified by the "><" inserted by the programmer and are talcen out of the source code and stored in one or 
20 more external message catalog files for later translation. A representative source version of the message catalog file for 
the "myApplication.java" file is as follows: 

$set 1 

25 [0024] 

1 Display adjustment 

2 Volume adjustment 

30 [0025] It is noted that the message catalog file contains simply the localizable display string and does not contain 
Java source code, thereby making it easily translatable. This source version of the message catalog file contains mes- 
sages and is not yet compiled. 

[0026] Next, at Block 46, an internationalization tool of the present invention modifies the Java source code to 
extract the identified localizable string(s), marked with "><", to one or more external, intermediate message catalog files 

35 when the Java program is compiled. Strings marked with *><" in the source files are extracted and converted to local- 
izable messages in output file(s), i.e. message catalog file(s). The localized messages in the message catalog file(s) 
are function calls to an intemationalizatlon tool-generated function that is used as an access to ListResourceBundle 
data structures for Java sources. For Java progranns, the internationalization tool converts the message catalogs into 
ListResourceBundle data structures. This activity occurs automatically when the Java program is compiled. It is trans- 

40 parent to the user and requires no intervention by the Java programmer. As will be described, the internationalization 
tool also generates the getString function. 

[0027] Continuing w'rth the given example, when the above Java program is compiled, the internationalization tool 
will intervene and modify the Java source code file "myApprtcation.java* so that it becomes the following: 

45 Locale locale; 

locale =: Locale.getDefaultO; 

public static ResourceBundle rb; 

rb = ResourceBundle.getBundleCmyResoupces", locale); 

myCheckboxl = new Checkbox(MsgHandler.getString("1 "," Display Adjustment) ; 
50 myCheckbox2 = new Checkbox(MsgHandler.getString("2","Volume Adjustment); 

[0028] The internationalization tool automatically generates a new Java dass, called "MsgHandler.java", having the 
definition of one method or function, called the "getStringO" method. A representative MsgHandler.java file that is auto- 
matk:ally generated by internationalization tool follows: 
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import java.util.*; 

public dass MsgHandler { 

public static String getString(String key, String defaultMessage) { 
//SECTION A of CODE 

if ({initialized) { 

Locale locale = null; 
//get the de^ult locale 

locale = Locale.getDefaultO; 

//SECTION B of CODE 

String localejanguage; 
locale Janguage = locale.getLanguage(); 
if (((locale Janguage.equalsCen'))) { 
try{ 

rb = ResourceBundle.getBundleCmyResources". locale); 

} 

catch (Exception ex) { 
rb = null; 

} 

}//lf 

else fb = null; 
initialized = taie; 
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15 



20 



25 



30 



} 

//SECTION C of CODE 

if (rb == null) return defaultMessage; 



//SECTION D of CODE 
String str, 
try{ 

str = rb,getString(key); 
} catch (Exception ex1) { 
str - defaultMessage; 

} 

return stn 

} 

private static ResourceBundle rb; 
^ private static boolean inttialized = false; 

} 

40 

[0029] This representative code of the internationalization tool autonnatically generates the MsgHandler.java class. 
The MsgHandler.java class consists of one method called 'getString'. The "getString" method performs various func- 
tional steps outlined in Sections A-D of the code and illustrated in the methodology of Rgure 4. It is recognized that the 
45 particular source code for the "MsgHandler.java" file may be different from that shown above without departing from the 
spirit and scope of the invention. 

[0030] Refening now to Rgure 4, methodology 50 of the "MsgHandler.java" file is illustrated. At Block 62, the cur- 
rent locale language being used by the Java program must be determined. Is the program cun^ently running in the Eng- 
lish, French, or Japanese languages, for Instance? Section A of the MsgHandler.java file above accomplishes this step. 

50 Next, at Decision Block 54, the inquiry is whether this current language is English, the default language. If it is, then the 
default English string that was passed into the "getString" method is returned at Block 55; this is accomplished by Sec- 
tion C of the MsgHandler.java file. If the current language is not English, then the flow continues to Block 56. At Block 
56, the language-specific version of the ListResourceBundle code is located, as Illustrated by Section B of the MsgHan- 
dler.java file. Next, the inquiry at Decision Block 58 is whether the language-specific version of the ListResourceBundle 

55 code exists. If it does not exist, the fiow goes to Block 55 to return the default English string that was passed into the 
"getString" method; this is demonstrated by Section 0 of the MsgHandler.java file code. If the language-specific version 
does exist, then the language-specific localized string from the ListResourceBundle is returned at Block 59, such as 
demonstrated by Section D of the above code. 
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[0031] The automatic call performed by the 'getString' method has a key benefit for performance. A call to open a 
LtstResourceBundle is relatively expensive in terms of the time required to make a call over a network and the 'get- 
String" method provides the advantage of minimizes such calls. Also, from Block 106 of Rgure 6, one can see that the 
intemationalizatlon tool will not even call the wrapper function of "getString" if the >< string has not been localized. This 
5 too represents a performance improvement because in this case there is no need to check for the locate information 
and the "getString' method is bypassed. 

[0032] In addition to this performance advantage, another advantage that is realized with the "getString" method is 
the ease with which Java software may be upgraded. This is best explained with an example. Suppose that the interna- 
tionalized Java program originally contained two localization strings, as in the above example. Those two strings were 
10 translated in the French language. When the Java program is executed, the getString method will attempt to retrieve the 
localized/translated French strings. Now, suppose that the Java programmer adds another "><" string to this program 
or even modifies an existing "x'string, such as: 

MyCheckboxl = new Checkbox ("xDisplay adjustment"); 
75 MyCheckbox2 = new Checkbox ("xVolume adjustment"); 
MyCheckboxS = new Checkbox ("xColor adjustment"); 

It can be seen that a new string for color adjustment as been added. 

[0033] When this modified Java program is processed by the internationalization tool, the new "x" string will not 

20 be replaced with the getString method call because the internationalization tool knows that this string has not yet been 
localized as stated in Block 102 of Rgure 7. As a result, this modified Java program can execute under the French lan- 
guage even though this new string does not even appear in the LtstResourceBundle associated with this French Java 
program, without throwing an exception. This allows the modified Java source code and ListResourceBundle to be 
decoupled, a condition that occurs when the ListResourceBundle data structure is not translated at the same time that 

25 the Java source code is modified without throwing an exception. 

[0034] The above model allows easier upgrade of the Java software. The process has effectively "de-coupled," or 
separated, two processes: the process of internationalizing the Java program via the "><" indk^tor, accomplished by 
Java programmers, and the process of translating the message catalogs, accomplished by the translators. Since these 
separate processes are de-coupled, they can occur independently. This is an important characteristk: when localizing 

30 software to any number of different languages for release at the same time-rather than releasing the English version 
first, followed by other language versions of the code. If these processes were not de-coupled in this manner, the Java 
program would always have to be in sync with the localized version of the ListResourceBundle data structure. This 
requirement is partbularly onerous in the typical situation in which there is a team of programmers in one country and 
another team of translators in a different country, ft is quite common that the team of translators are almost never on- 

35 site with the programmers. Moreover, the costs associated with translation may be prohibitive but, with the present 
invention, it is no longer necessary to always perfomi translation of modified or added strings at the time that the Java 
source code is modified. 

[0035] Now that internationalization of the Java program has been performed, the next step is translation of the 
localizable strings stored in the message catalog file. Referring now to Rgure 5, flow chart 60 illustrates the methodol- 

40 ogy of the present invention for translating the localizable string(s) and how the localized ListResourceBundle is gener- 
ated. At Block 62, the message catalog file associated with the Java package of related Java source code fifes is 
ot>tained. As previously mentioned, it does not contain source code, containing only the display strings, and is therefore 
readily translatable. Next, at Block 64, the localizable display strings in the message catalog file are translated. Contin- 
uing with the above-described message catalog for the "myApplication.java" file, the Frerrch translated version of the 

45 message catalog is: 

$set1 
[0036] 

50 

1 Re'glage d'affichage 

2 Re'glage de volume 

[0037] Following the translation, the internationalization tool will again intervene and process the translated mes- 
55 sage catalog to automatically generate the translated version of the LtstResourceBundle Java code, at Block 66. Sam- 
ple Java code in file "myResources_fr.java' automatically generated by the intemationaltzation tool would be: 
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import java.util.*: 

public class myResources_fr extends ListResourceBundle { 
public ObjectQQ getContents() { return contents }; 
static final ObjectQQ contents - { 

{"1", "Re'glage d'affichage"}, 

{"2", "Re'glage de volume"}, 

}; 



[0038] As previously discussed, the Java programming language uses ListResourceBundle to create localizable 
2o strings. The internationalization tool generates X/Open Portability Guide style message catalogs as intermediate files 
from which ListResourceBundle may be generated. 

[0039] A more detailed example of the methodology of the present invention is presented in the flow diagrams of 
Rgures 6-7. Consider for purposes of this example that the internationalization tool is referred to as "Msgs." Refem'ng 
now to flow diagram 70 of Rgure 6, Blocks 72-84 illustrate in greater detail the methodology of the present invention 

25 for Implementing Block 46 of Figure 3. After identifying localizable strings and inserting *><" for each identified string as 
shown at Blocks 42 and 44 of Rgure 3, the intemationalizatlon tool Msgs is run on each of the Java class files that con- 
tain the "><' localizable strings to extract the localizable strings and generate a new version of the Java dass file in a 
new directory as shown at Blocks 72 and 74. At Block 72, Msgs extracts the "><" strings into an intermediate message 
catalog, and at Block 74, Msgs generates a new version of the Java class file in the directory from which Msgs is run. 

30 Msgs is executed in the following manner: 

Msgs -J $NLS_CAT -d $PRENLS_DIR -n $NLS_DIR -D . -K\ 
-p $PACKAGE_NAME $SOURGE_DIR/$SOURCE_FILE 

35 in whteh -J specifies "Java mode" and -c $NLS_CAT specifies the name for the message catalog, -d $PRENLS_DIR 
specifies the path to the pre-nis directory and this path may be a relative path; the pre-nls directory specified by 
$PRENLS_DiR contains the original message catalog file that was translated before, -n $NLS_DIR specifies the path 
to nls/G directory and this specification may also be a relative path. nIs/G is a directory that will contain a new message 
catalog file that is effectively the entire contents of pre-nls/$NLS_GAT file with all of the new and modified messages 

40 that were found in the Java program. This new message catalog is called nls/G/$NLS_GAT file. Once this new 
nls/G/$NLS_CAT file is translated, it will replace $PRENLS_DIR/$NLS_GAT file. -D path specifies the destination for the 
output of the modified version of the Java class. The programmer should take care to not overwrite the original Java 
class file by specifying a different location than the original source location. -K is for the multiple message mode and 
must be specrfied. -p $PAGKAGE_NAME specifies the complete name of the Java package to which the partknjiar Java 

45 class belongs. $SOURCE_DIR is the path to the directory that stores the localizable Java class files identified by "x". 
This directory should be different from the directory from whk:h the Msgs intemationalizatlon tool is executed, i.e. the 
value being passed to the -D option. $SOURGE-FILE is the name of the Java class file containing the localizable 
"x'strings. The execution of Msgs by the foregoing commands generates files in the $NLS_DIR directory and also 
rewrites a modified version of the .Java file. 

50 [0040] At Block 76, from within the same $NLS_D1R directory, the MsgHandler.java file is generated. MsgHan- 
dler.java file will be used by the Java code to retrieve the "><" localizable strings from a ListResourceBundle dass. 
Please refer to Figure 4 and the foregoing discussion for a detailed description of the MsgHandler.java file. The Msgs 
internationalization tool is executed in the following way to generate the MsgHandler.java file: 

55 Msgs -d-Q-c $NLS_CAT -d $PRENLS_D1R -n $NLS_DIR \ 
-P $PAGKAGE_NAME -B $BUNDLE_NAME 

in which -J specifies "Java mode", -g specifies the "TMsgHandlerjava" generate function, -c $NLS_GAT specifies the 
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name for the message catalog described above, -d $PRENLS_DIR specifies the path to the pre-nis directory described 
above, -n $NLS_DIR specifies the path to the nIs/C directory described above, -p $PACKAGE_NAME specifies the 
complete name of the Java package to which this Java class belongs as described above, and -b $BUNDLE_NAME 
specifies the name to be used for the ListResourceBundle class that Msgs will generate (for instance, 
5 "SNLS.CAT'Res). The foregoing code will cause Msgs to generate a new file called MsgHandter.java as shown at Block 
76. 

[0041 ] Next, at Block 78, the Msgs internationalization tool generates a merged intemnediate message catalog file. 
Msgs is executed in the following manner: 

10 Msgs -J-M^ $NLS_CAT -d $PRENLS_DIR -n . 

In which -J specifies "Java mode', -M specifies a merge mode, -c $NLS_CAT specifies the name for the message cat- 
alog (described above), -d $PRENLS_DIR specifies the path to the pre-nIs directory described above, and -n specifies 
the cun-ent directory. This language will cause the Msgs tool to generate a message catalog-like file called $NLS_CAT.1 
15 that contains the merged messages from pre-nls/$NLS_CAT.1 and the files in the current directory. At Block 80, the 
intermediate file nls/C/$NLS_CAT.1 generated by the Msgs tool is now available for localization, i.e. translation into 
another native language as shown at Block 64 of Rgure 5. 

[0042] At Block 82, the programmer changes to the $NLS_DIR directory from which the Msgs tool generates a Lis- 
tResourceBundle file from the intermediate message catalog file. As an example, MsgsP, a Peri script and not the Msgs 
20 executable, is executed in the following manner: 

MsgsP_ $NLS_CAT1 $BUNDLE_NAME$PACKAGE_NAME 

In which $NLS_CAT specifies the name for the message catalog (described above), $BUNDLE_NAME specifies the 
25 ListResourecBundle class name (described atx)ve), and $PACKAG E_NAM E specifies the Java package name to whk;h 
this ListResourceBundle belongs. MsgsP is run for each translated (localized) version of the message catalog. For 
instance, if you have a Japanese version of the message catalog stored in the nls^apanese file, MsgsP is run on nls/jap- 
anese/$NLS_CAT.1 as well. 

[0043] Rnally, at Block 84 all of the .java files are compiled, including the MsgHandler.Java and 

30 $BUNDLE_NAME.java files. 

[0044] The flow diagram 90 of Rgure 7 further illustrates the methodology of the present invention, with particular 
emphasis on identifying modified strings that require new translations. At Block 92, the original Java file is opened and 
next, at Block 94, the pre-nIs message catalog file is opened. At Block 95, the pre-nIs message catalog file is copied to 
the nis message catalog file. A modified Java file is created (see Step 74 of Rgure 6) at Block 96. At Block 98 the con- 

35 tents of the original Java file are read Into a buffer or other temporary storage area of a computer on whch internation- 
alization tool Msgs is running. Next, at Decision Block 100, the inquiry is whether the string from the original Java file 
read into the buffer contains 'x' to indk^te that rt has been previously identified as a localizable string. If yes, then the 
inquiry, at Block 102, is whether the 'x' string exists in the pre-nts message catalog file. If no, then the string is 
appended to the nIs version of the message catalog file, typically at the end of the message catalog file, at Block 104 

40 and the "x" are removed in the buffer at Block 1 06 to leave the default English string. If yes. the message number asso- 
ciated with the string is obtained at Block 108 and this "><' string is replaced in the buffer with a method call to 
''MsgHandler-getString( )" that can obtain the localized string at Block 1 1 0. The flow continues to Block 112. 
[0045] Also from Decision Block 1 00, if the buffer does not contain a '><" string, the mod'rfied Java file is written 
from the buffer at Block 112. Decision Block 112 inquires as to whether there are any more strings in the buffer, If the 

45 end of the file has not been reached, then the flow returns to Block 98 from Decision Block 1 1 4. If the end of the file has 
been reached, however, the flow continues to Block 116. Rnally, the original Java file, the pre-nIs and nIs message cat- 
alog files, and the modified Java file are closed at Blocks 1 16-120. 

[0046] An advantage of the methodology of Rgure 6 is illustrated by Blocks 1 04 and 1 05. When a string does 
not already exist in the message catalog specified by $NLS_CAT and stored in $PRENLS_D1R, this indicates that the 

50 string is new or has been modified and hence it has never been localized. This new, or modified, string is appended to 
the bottom of the copied version of the message catalog $NLS_DIR/$NLS_GAT It is this $NLS_DIR/$NLS_CAT file, 
and not the $PRENLS_DIR/$NLS_CAT file, that is actually sent to the translators for translation. Because all of the new 
and/or modified strings are appended to the bottom of the file, the translators can easily identify whbh strings to trans- 
late, thereby significantly speeding up the translation effort 

55 [0047] The present invention solves a number of problems associated with internationanzation of Java-t)ased soft- 
ware and apprications. Rrst, the present invention generates message catalogs automatically from a given Java source 
code, which can then be used for translation. The autonoatic generation of message catalogs from Java source code 
avoids having to translate ListResourceBundle data structures whbh are difficult to translate. Next, the present inven- 
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tion automatically generates the ListResourceBundle data structures from the compiled or processed version of the 
message catalogs that were generated and translated so that the final result is compatible with Java's Internationaliza- 
tion model. Additionally, the present invention automatically modifies the Java source code so that it loads and 
accesses ListResourceBundle data structures, thereby overcoming the cumbersome prior art procedure of having to 

5 write Java code that loads and accesses ListResourceBundle data structures. 

[0048] The methodology of the present invention thereby provides a number of advantages over the prior-art meth- 
odology. The method is transparent to the user and provides a greatiy needed degree of flexibility and consistency in 
internationalization of Java-based software in the art The present invention is also time-saving. There is no need to 
extract strings from the source code for message catalogs; this step is automatically performed by the intemationaliza- 

10 tion tool of the invention. Moreover, the present invention is much faster in that a time-consuming call to open a ListRe- 
sourceBundle is not executed if a "><" string has not been localized. This provides for faster execution of the Java code. 
Also, de-coupling the process of translating strings from the process of internationalizing the Java code allows for ease 
of maintaining the software. The appending of new and/or modified translatable strings to the end of the 
$NLS_DIR/$NLS_CAT file makes it easy for the translator to find the strings to be translated at some future time. 

15 [0049] While the invention has been particulariy shown and described with reference to a preferred embodiment, it 
will be understood by those skilled in the art that various changes in form and detail may be made therein without 
departing from the spirit and scope of the invention. While only two strings have been discussed in the examples 
described above for ease of explanation, one skilled in the art will recognize that there are typically hundreds or even 
more localizable strings. With this great number of strings typk^lly found in Java source code, it can be seen that the 

20 job of translating and maintaining the strings is extremely cumbersome using prior art approaches. The present inven- 
tion greatiy improves the efficiency and ease with which global Java source code may be written and maintained. 

Claims 

25 1 . A method for generating localizable message catalogs for Java-based applications, comprising: 
identifying one or more localizable strings of a Java source code (42); 

marking the one or more localizable strings to produce one or more marked localizable strings by inserting a 
30 marker into each localizable string of the one or more localizable strings (44); 

extracting the one or more marked localizable strings (74); 

storing the one or more marked localizable strings into an extemal text file (46); and 

35 

generating one or more ListResourceBundle cteta structures from the one or more marked localizable strings 
stored in the extemal text file (82). 

2. The method of claim 1 , wherein extracting and storing the one or more marked localizatHe strings into one or more 
40 text files and generating the one or more ListResourceBundle data structures occurs when the Java source code 

is compiled (84). 

3. The method of claim 1 , wherein generating one or more ListResourceBundle data structures from the one or more 
nrtarked localizable strings comprises for each marked localizable string of the one or more marked localizable 

45 strings: 

detemnining a cunent locale language in which the Java source code is running (52); 
determining whether the current locale language is a default language (54); 

50 

if the cunnent locale language is the default language, retuming a marked localizable string of the one or more 
marked localizable strings (55); 

if the current local language is not the default language, detennining whether a language-specific version of 
55 the marked localizable string that corresponds to the current locale language exists in a ListResourceBundle 

data structure of the one or more ListResourceBundle data structures that corresponds to the marked localiz- 
able string (58); and 



13 



EP1 100 004A2 



if the language-specific version exists, opening the ListResourceBundle that corre^onds to the marked local- 
izable string and returning the language-specific version of the marked localizable string from the ListRe- 
sourceBundle (59). 

The method of claim 1 , further comprising translating the one or more marked localizable strings of the Java source 
code, wherein translating the one or more localizable strings comprises: 

obtaining the extemal text file containing the one or more mariced localizable strings (62); 

translating the one or more mariced localizable strings stored in the extemal text file (64); and 

generating a ListResourceBundle data structure for the translated one or more marked localizable strings (66). 

A method for generating localizable message catalogs for Java-based applications, comprising: 

Identifying one or more localizable strings of a Java source code (42); 

noaricing the one or more localizable strings to produce one or more marked localizable strings by inserting a 
nnarker into each localizable string of the one or more localizable strings (44); 

extracting the one or more marked localizable strings (46); 

storing the one or more marked localizable strings Into an external text file in a first directory (46, 72); 

generating a new version of the Java source code in a second directory from which an internationalization tool 
is run (74); 

retrieving the marked localizable strings from a ListResourceBundle dass (76); 

generating a merged external text file containing the one or more marked localizable strings in the first direc- 
tory and the second directory (78); 

generating one or more ListResourceBundle files corresponding to the merged extemal text file with each Lis- 
tResourceBundle file of the one or more ListResourceBundle files corresponding to a desired language (82); 
and 

compiling the one or more ListResourceBundle files and the Java source code (84). 

The method of claim 5, wherein retrieving the marked localizable strings from a ListResourceBundle class com- 
prises: 

detemiining a current locale language in which the Java source code is mnning (52); 
determining whether the current locale language is a default language (54); 

if the current locale language is the defautt language, retuming a marked localizable string of the one or more 
marked localizable strings (55); 

if the current local language is not the default language, determining whether a language-specific version of 
the marked localizable string that corresponds to the current locale language exists in a ListResourceBundle 
data structure of the one or more ListResourceBundle data structures that con^esponds to the marked localiz- 
able string (58); and 

if the language^pedfic version exists, opening up the ListResourceBundle that corresponds to the marked 
locaPtzable string and retuming the language-specific version of the marked localizable string from the ListRe- 
sourceBundle (59). 

The method of claim 5, wherein after generating a merged extemal text file, further comprising: 
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translating the one or more marked localizable strings in the merged extemal text file into one or more desired 
languages (80). 

A method for generating localizable message catalogs for Java-based applications, comprising: 

opening an original Java source code file that is stored in a first directory (92); 
opening a first message catalog file (94); 

copying the first message catalog file to a second message catalog file (95); 

creating a modified Java source code file from the original Java source code file in a second directory (98); 
reading the contents of the original Java source code file into a buffer (98); 

rf the buffer contains one or more marked localizable strings (1 00). for each marked localizable string of the one 
or more marked localizable strings comprising: 

determining if the marked localizable string is stored in the first message catalog file (102); 

if the marked localizable string is stored in the first message catalog file, comprising: 

obtaining a message number con-esponding to the marked localizable string (108); and 

replacing the mariced localizable string in the buffer with a method call that can obtain the marked 
localizable string (110); 

if the marked localizable string is not stored in the first message catalog file, comprising: 

appending the marked localizable string to the second message catalog file (104); and 

removing a marker from the marked localizable string in the buffer to convert the marked localizable 
string to a default localized string (1 06); 

writing to the modified Java source code file from the buffer (112); and 

closing the original Java source code file, the first message catalog file, the second message catalog file, and 
the modified Java source code file (1 1 6, 1 1 8, 120). 

A method for generating localizable message catalogs for Java-based applications, comprising: 

generating a plurality of modified Java source code files (96); 

generating a message catalog file having one or more localizable strings for a Java package (42, 44); 
translating the message catalog file manually (64, 80); 

generating a plurality of ListResourceBundle data structure files for the one or more localizable strings of the 
translated message catalog file (66, 82); and 

compiling the plurality of modified Java source code files and the plurality of ListResourceBundle data structure 
files (46, 84). 
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